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The Display feature 52 can display different views of the devices 12-22 of the 
internet 1 0. The views can be arranged in different ways. Views of desired 
system resources can be displayed. For example, a single view of all managed 
routers on the network could be displayed, regardless of the actual location of 
the routers in the network hierarchy. Or, views of devices can be arranged in 
a hierarchy to depict various levels of the internet 10. The highest level of 
the hierarchy, the internet 10, can be displayed as a network glyph. The 
network administrator can "navigate" through the internet 10 by simply pointing 
a mouse and double clicking the glyph which refers to the view. 
Double-clicking the network glyph of the internet 10 would cause the Console 
program 44 to display the next level, which would include cloud glyphs for the 
subnetworks S1, S2, S3 and S4, glyphs of the intermediate systems 12-18, and 
glyphs of the physical links . 
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ABSTRACT 



A network management system allows a user to generate a 
customized event request for network accessible devices. In 
response to a user request the system displays a list of 
devices, and a list of predefined event requests. In response 
to user customization commands the system generates cus- 
tomized event requests by associating various ones of the 
displayed devices with various ones of the displayed pre- 
defined event requests. At most one predefined event request 
is associated with each device. The network management 
system periodically sends the customized event requests to 
the devices with which they have been associated, and 
receives response messages from those devices. A display or 
report may be generated showing the status of the respond- 
ing devices, using the information in the received response 
messages. A predefined event request may be formed by 
storing one or more variable/threshold pairs in a predefined 
event request data structure. The network management sys- 
tem allows an administrator to define or change the system 
by associating devices with predefined event requests, elimi- 
nating the need to write or modify computer programs. 

22 Claims, 4 Drawing Sheets 



Network 
Topology 



Struct!© Rte5 
instance Rles 



Update Fies 
Create Fles 



DspJay 



Display Glyphs 
Ofepfay Views 



CM 



Glyph 



Color 
Brightness 



Console 
Program 



GUI 



Auto Manage 



r 



Auto Management 



Ka log Box 



Default 
Custom 
Generate Customized 
Roquests 



Agent 



AdonMBs 



Inputs 



Keyboard 
Mouse 



Generate Inputs 



Create Request 



Generate Redefined 
Requests 



U.S. Patent jui.27,1999 sheet 1 of 4 5,930,476 




FIGURE 2 



U.S. Patent 



Jul. 27, 1999 Sheet 2 of 4 



5,930,476 



.44 



42 



1 



Network 
Topology 
Database 



Structure Files 
Instance Files 



Update Files 
Create Files 



Console 
Program 



GUI 



Auto Manage 




L 



46 



Auto Management 



Dialog Box 



Default 
Custom 
Generate Customized 
Requests 



50' 



l,M 



45 



Inputs 



Keyboard 
Mouse 



Generate Inputs 




Generate Redefined 
Requests 



FIGURE 3 



U.S. Patent jui.27,1999 sheet 3 or 4 5,930,476 
FIGURE 4 

B SunNet Manager Console: Customized Automatic Managment 

Default Auto Mgmt for Components without Customized Requests? Ef 
Component: Predefined Requests: 

bridge 
genhost 
genws 
hub 
ipc 

router 1 
router2 



Custo mized Automatic Management Requests: 

|l ss2:when Disk is Full 

ss10:when Disk is Full 
routert:router1_test 



if System Reboot 



when Disk is Full 



when Printer Error 

when System is not Reached 

routeM Jest 

router2_test 



(Add) 



(Delete) 
(Change) 



(Apply) (Reset) ( Create Predefined ... ) 



Execute Console Program 



Generate GUI 



Display Glyphs 



Select Views 



Display Menu Bar 



100 
102 
104 
106 
108 



FIGURE 5 



U.S. Patent Jul. 27, 1999 Sheet 4 of 4 



5,930,476 



FIGURE 6 



Select Auto Management Feature 



I 



Generate Properties Dialog Box 

* 



Enable Auto Management 



1 



Select Management Behavior 



200 



202 



204 



206 




FIGURE 7 



300 



Click on Customize Button 

1 ~ 

302 H Components 



FIGURE 8 



4 



Select Create Predefined Request 



304 « 



306^ 



308 * 



310> 



312- 



Read Predefined Event Requests 



I 



Generate Window 



400 



-402 



Display Components and Requests 



Display Fields 



— 404 



Associate Components with Requests 

— 1 



1 



Display Customized Requests 



Fill-in Name, Attributes List 



-406 



Save Predefined Event Request 



— 408 



Save Customized Requests 



5,930,476 

1 2 

APPARATUS AND METHOD FOR A computer storage medium stores a plurality of execut- 

GENERATING AUTOMATIC CUSTOMIZED able instructions which instruct a computer to automatically 

EVENT REQUESTS monitor a plurality of network devices. The plurality of 

1Iwini ™ ....... 1Kn/CKrnnM instructions comprises instructions which instruct the corn- 

BACKGROUND OF THE INVENTION 5 pmcf {q ^ a F plurality of prcdcfincd cvcnt requcsls; 

The present invention relates to digital communications. instructions which allow the computer to associate the 

More specifically, the present invention relates to network predefined event requests with at least some of the network 

management. devices; and instructions which instruct the computer to 

Today, large numbers of personal computers and work- send the predefined event requests to their associated 

stations are being interconnected with file servers, print 10 devices. 

servers, modems, hubs and other devices to form local area Apparatus for automatically monitoring a plurality of 
networks, metropolitan area networks and wide area net- devices on a network comprises memory for storing a 
works. These networks allow the personal computers and plurality of different predefined event requests; and a pro- 
workstations to share information and valuable resources cesser for reading the predefined event requests, associating 
among each other. Now more than ever, individuals and is appropriate event requests with at least some of the devices 
companies depend on networks to conduct business and to [ n resp onse to user inputs, and firing the associated event 
communicate with people around the world. Indeed, the requests. 

network has become the computer. A manager {qt communicating with a plurality of 
Most networks use a network manager and some form of network agents emprises a com puter that is programmed to 
Simple Network Management Protocol (SNMP) for man- 20 read a plurality of predefined event requests; associate the 
aging the network. Among its management tasks, the net- pre defined event requests with the plurality of agents; and 
work manager automatically monitors the status of the send the predefined event requests to their associated agents, 
devices on the network. The network manager sends pre- 
defined event requests to the devices, which are requested to BRIEF DESCRIPTION OF THE DRAWINGS 
return responses when certain events occur. For example, a 25 

disk agent might be requested to send a response if available FIG. 1 is a schematic diagram of an internet including a 

disk space falls below 50%. There are times when an event network manager according to the present invention; 

request might not define important events for a device, FIG. 2 is a block diagram of the network manager 

especially when the device is manufactured by more than according to the present invention; 

one vendor. An SNMP-manageable device stores in its 30 FIG. 3 is a static object oriented model of software that is 

memory a Management Information Base (MIB), a collec- executed by the network manager according to the present 

tion of objects or variables representing different aspects of invention' 

the device (e.g configuration, statistics, status, control). For mQ ^ an mustration of , dial box for customizing 

each class of device, the MIB has a core of standard ^ (he ^ box ^ ^ „ (he 

variables. Each vendor of a device will add to the core, 35 4 , D , * • 

, ^ r " ! - 4 c ' network manager according to the present invention; 

variables that it feels are important to the management of its mrt „ . „ . 

device. Thus, the MIB for a router from a first vendor might mG - 5 15 a flowchart of initial steps performed by the 

be different from the MIB for a router from a second vendor, net work maQa S er according to the present invention; 

and an event request that defines important events for the FIG. is a flowchart of steps for monitoring the health of 

one router might not necessarily define the same important 40 the work; 

events for the other router. This is a problem with network FIG. 7 is a flowchart of steps for creating customized 

managers. requests; and, 

Another problem is that current network managers do not FIG. 8 is a flowchart of steps for creating a predefined 

easily allow the health of the devices to be defined. The event request, 

health is "hard-wired" into the event requests. Yet the 45 

desired definition of a healthy device or system might not DETAILED DESCRIPTION OF THE 

concur with the predefined definitions. For example, a router INVENTION 

could have five devices attached, two of which are redun- „ . . 

dant. Even if one of the redundant devices is bad, the router l shows an m * m * 1 ll nQ ™ m Z ^f^ond, third 

is still good. However, the network manager would indicate 50 and fourth subnetworks SI, S2, S3 and S4 that are inter- 

that the router is bad. connected by intermediate systems 12, 14, 16 and 18. For 

illustrative purposes only, the first and second subnetworks 

SUMMARY OF THE INVENTION si and S2 are of a first topology, such as Token ring, the 

These problems are overcome by methods, computer third and fourth networks S3 and S4 are of a second 

storage medium and apparatus according to the present 55 topology, such as Ethernet, the first and second intermediate 

invention. A method of monitoring a plurality of network systems 12 and 14 are bridges 12 and 14, and the third and 

devices comprises the steps of reading a plurality of pre- fourth intermediate systems 16 and 18 are first and second 

defined event requests from computer memory; associating routers 16 and 18. The first router 16 is manufactured by one 

at least some of the devices with the predefined event vendor and the second router 18 is manufactured by a 

requests; and sending the predefined event requests to their eo different vendor. MIBs of the first and second routers 16 and 

associated devices. 18 have the same core of variables, but they have different 

A method of generating an event request for a network variables added to their cores. Thus, the MIBs of the first and 
device comprises the steps of forming a plurality of pre- second routers 16 and 18 are different, 
defined event requests; and associating one of the plurality The first subnetwork SI includes a first group of addres- 
of predefined event requests with the device. At least two of 65 sable devices 20, the second subnetwork S2 includes a 
the plurality of predefined event requests are formed by second group of addressable devices 22, the third subnet- 
different attributes lists. work S3 includes a third group of addressable devices 24, 
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and the fourth subnetwork S4 includes a fourth group of element. The instance files contain instances of structure 

addressable devices 25. The addressable devices 20, 22, 24 files for the elements that have been discovered on the 

and 25 can be devices such as workstations, personal internet 10. For a description of net work topology databases, 

computers, printers and hubs. Each device 20, 22, 24 and 25 see C. Malamud, "Analyzing Sun Networks", Van Nostrand 

is associated with an MIB and an agent. The agent is a 5 Reinhold (1992) pp. 419-21, which is incorporated herein 

software program that may or may not be resident in the by reference. 

device. TCP/IP is used to regulate how data is packeted and The Console program 44 includes an object-oriented, 

transported between the devices 20, 22, 24 and 25. Each graphical user interface (GUI). The GUI can be derived from 

device 20, 22, 24 and 25 has a physical or medium access Open Windows™ 3.1 or later or any other library of classes 

control (MAC) address and a unique IP address. 10 for GUIs. Inputs 45 are supplied to the GUI via a mouse and 

The internet 10 also includes a network manager 26, a keyboard. When executed, the Console program 44 dis- 

which is connected to the third subnetwork S3 and which has plays a menu bar that allows the various features described 

access to the MIB of each device 20, 22, 24 and 25. SNMP below to be selected. 

is the protocol used for managing the devices 20, 22, 24 and The Console program 44 has an Auto Management fea- 

25. The agents allow a network manager to access the MIB 15 ture 46 that monitors the health of the internet 10. When the 

of each device. Such accessibility allows the network man- Auto Management feature is selected, a "Properties" dialog 

ager to control operations of the agents, analyze resource box is displayed. The Properties dialog box offers the 

performance, identify and resolve faults, and automate man- following options: 

agement tasks. For example, the network manager can Automatic Management: Enable/Disable 

request an agent to change the value of a variable in the MIB 20 Management Behavior: Default/Custom Customize but- 

of a device, and it can request an agent to send out a response t 

when an event occurs, such as a MIB variable exceeding a Aulom atic Management is performed when the Enable 

threshold. For a general description of network button is selected. Event requests are automatically started 

management, see W. Stalling* "Data and Computer fof me devices 20 22> 24 and ^ in the nctwork topology 

Communications , MacMdlan (4th ed, 1994) pp. 701-24, 25 database 42 . event requests are repeated at every poUing 

which is incorporated herein by reference. interval. For example, a polling interval of 600 would cause 

FIG. 2 shows the network manager 26 in greater detail. cvent requests to be sent every 600 seconds. When an event 

The network manager 26 includes a workstation 28 such as request is fired, it is sent to an agent 48 of the device at the 

a SPARCstation™orSPARCserver™.Bothof these work- destination address specified in the event request's outer 

stations use a RISC-based high-performance "SPARC" message wrapper. 

microprocessor 30. The SPARCstation™, SPARCserver™, if the Default button for Management Behavior is also 

and "SPARC microprocessor are all commercially avail- selected, one of the following default event requests is sent 

able from Sun Microsystems, Inc., the assignee of the at everv polling interval (with order preserved): 

present invention. The workstation 26 is configured with a (i)SNMP Event Request(ifoperStatus not equal to 1). 

color display monitor 32 and a CD ROM drive 34 for (2)Hos tperf Event Request(u P Time increased by 

distribution media. It is also configured with volatile v < number \ 

memory 36 (e.g., 32 Mbytes of DRAM) and non-volatile /„vt™«, t « . ™ ./ ^ li 1 . r 1 \ 

memory 38 (e£ a 4O0 Mbyte hard drive). £>™ «*° f Ev f, nt Request(reachable equal to false). 

' ; B \ / . ; J <„ 1MV „ What these default event requests determine is whether 

Software for the network manager includes a UNIX - ^ me devices 2Q 22> 24 aQd 25 in the network topology 

based operating system 40. Operating systems for the da(abase 42 m operative< If a device supports SN MP, the 

"SPARC" microprocessor include "SOLARIS" 2.4 or network manager 26 sends the SNMP Event Request to the 

greater and "SOLARIS" 1.x or later. The "SOLARIS" deyice [f if0 p e rStatus is not equal to 1, an event is gener- 

operating systems are also commercially available from the ated If the device does not support SNMp> but does support 

assignee of the present invention. The operating system 40 45 Hostperf) tne network man ager 26 sends the Hostperf Event 

is stored on a portable computer memory medium (e.g., a R t tQ (he devjce , f upTime faas increased by a number 

CD ROM) and loaded onto the non-volatile memory 38 such ^ u aQ event fe generated . Instead of OperStatus not 

from the CD ROM drive 34. being equal (0 t and up71me being increased by 1, other 

Additional software for the network manager 26 includes criteria can be used to generate events. If the device does not 

a network topology database 42 and a Console program 44 50 support SNMP or Hostperf, it is sent an ICMP Event 

that automatically displays and manages the devices indi- Request, which requests the device to send back a response 

cated by the network topology database 42. The Console indicating reachability. 

program 44 can be stored on a portable computer medium if tne Custom button for Management Behavior is 

and loaded onto the non-volatile memory 38 from the CD selected instead of the Default button, the network manager 

ROM drive 34. The network topology database 42 can be 55 26 sends customized event requests to associated component 

created dynamically by a discover tool, which is executed by types. The customized event requests are read from the 

the workstation 26. The network topology database 42 is network topology database 42. 

also stored in the non-volatile memory 38. The Auto Management feature 46 allows the customized 

Referring now to FIG. 3, the network topology database event requests to be generated. By clicking on the Customize 

42 is a collection of structure or schema files and instance 60 button, a Customize popup dialog box appears. The Cus- 

files that describe the internet 10. Four basic elements are tomize popup dialog box shown in FIG. 4 includes three 

components (e.g., printers, routers, workstations), views columns: a Component column, a Predefined Request col- 

(collections of elements, including other views), buses (e.g., umn and a Customized Automatic Management Requests 

a Token Ring segment) and connections (e.g., an RS-232 column. The Component column lists the components (e.g., 

link). Structure files for other elements can be added to the 65 bridge, genhost, genws, hub, ipc, routerl, router2), which 

network topology database 42. Each structure file includes a are read from the network topology database 42. Note that 

number of records that describe the structure of a particular routerl and router2 correspond to the first and second 
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routers 16 and 18, which were manufactured by different 
vendors. The components that are displayed might not 
constitute all of the devices 20, 22, 24 and 25 on the internet 
10, but only those devices in a particular cluster or view. The 
Predefined Request column lists the predefined requests 5 
(e.g., if_System_Reboot, when__Disk___is__Full, when_ 
Printer_Error, wben_System_Js_Not_Reachable, 
routerl_test, router2_test), which are read from a Pre- 
defined Request file stored in the non-volatile memory 38. 
Note that the routerl„test for the first router 16 is different 
than the router2„test for the second router 18. 

Customized event requests are generated by associating 
the components in the Components column with the pre- 
defined event requests in the Predefined Request column. A 
component and a predefined event request could be 
associated, for example, by selecting a component from the 15 
Component column and a predefined event request from the 
Predefined Requests column. The Customized Automatic 
Management Requests column lists the pairs of associated 
components/requests. For example, routerl from the Com- 
ponent column and route rl_tesl from the Predefined 20 
Request column are selected, and the routerl :routerl_test is 
displayed in the Customized Automatic Management 
Requests column. Only one predefined request is associated 
with each component type. This is done to reduce traffic on 
the internet 10. Besides, multiple requests for a device are 25 
not really needed since each predefined event request can 
define multiple events. The predefined event requests dis- 
played in the Customized Automatic Management Requests 
column are stored in the network topology database 42 in the 
instance files of their associated component. It is once again 30 
noted that the Customize dialog box of FIG. 4 is merely 
exemplary, and that the interface for associating the com- 
ponents and predefined event requests is left up to the 
designer of the Console program 44. 

When the box for Default Auto Mgmt for Components 35 
w/o Customized Requests is checked (near the top of the 
dialog box in FIG. 4), the default event requests are sent as 
described above to the devices that have not been associated 
with predefined event requests. That is, one of default 
requests (1), (2) and (3) is sent to each of the devices that 40 
have not been associated with predefined event requests. If 
the button is not checked, no event requests at all are sent to 
those devices. 

When the Create Predefined button (at the bottom of the 
dialog box in FIG. 4) is clicked on, a Create Request window 45 
50 is displayed. Hie Create Request window 50 allows a 
predefined event request to be created. For a general illus- 
tration of an event request, see C. Malamud, "Analyzing Sun 
Networks", Van Nostrand Reinhold (1992) pp. 421-24. The 
Create Request window 50 displays certain fields of a 50 
predefined event request and allows the user to fill in a name 
of the predefined event request (e.g., Disk _Available) and 
an attributes list. For example, three pairs of variables/ 
thresholds are added to the attributes list. One of these pairs 
defines events based on disk availability. This allows the 55 
Disk_AvaiIable event request to instruct the genws to return 
Response messages when disk availability exceeds 15%. 
Similarly, the routerl_test event request could query the 
attributes related to the first router's interface status and send 
an event when all of the interfaces are down. The threshold 60 
is selected solely at the discretion of the network adminis- 
trator or other superuser. After the fields are filled out, a save 
button is clicked on and the predefined event request is 
added to the Predefined Request file. Even though different 
devices have different functionalities, the event requests can 65 
be configured for the device under consideration. Thus, the 
network administrator can define the health of the device. 
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The Console program 44 also has a Display feature 52 that 
allows the devices 20, 22, 24 and 25 in the network topology 
database 42 to be displayed. The devices 20, 22, 24 and 25 
are represented by glyphs 54. Glyphs 54 have attributes such 
as color and brightness that provide additional information 
about the devices they represent. 

The Display feature 52 can display different views of the 
devices 12-22 of the internet 10. The views can be arranged 
in different ways. Views of desired system resources can be 
displayed. For example, a single view of all managed routers 
on the network could be displayed, regardless of the actual 
location of the routers in the network hierarchy. Or, views of 
devices can be arranged in a hierarchy to depict various 
levels of the internet 10. The highest level of the hierarchy, 
the internet 10, can be displayed as a network glyph. The 
network administrator can "navigate" through the internet 
10 by simply pointing a mouse and double clicking the glyph 
which refers to the view. Double-clicking the network glyph 
of the internet 10 would cause the Console program 44 to 
display the next level, which would include cloud glyphs for 
the subnetworks SI, S2, S3 and S4, glyphs of the interme- 
diate systems 12-18, and glyphs of the physical links. 

Certain colors can notify the network administrator of 
events relating to a device. Perhaps the event was a router 
that went down or a hard drive having less than 10% of disk 
space available. A glyph for any of these devices could be set 
to a color such as red. If available disk space increased to 
50%, the glyph could be changed to an orange color. If the 
disk space availability increased to 75%, the color of the 
glyph could be changed to green. 

Event requests can be sent manually to selected devices. 
By clicking the glyph menu of the selected device, the 
network manager 26 looks up the associated event request in 
the network topology database 42 and fixes the event request 
to the selected device. 

FIGS. 5 to 8 show the operation of the network manager 
26. Reference is made first to FIG. 5. When the Console 
program 44 is executed (step 100), the network manager 26 
generates the GUI (step 102). The GUI displays the glyphs 
54 (step 104). The network manager 26 can color-code the 
glyphs in response to the responses from the devices. Using 
a mouse or keyboard, the user selects a particular view of the 
network (step 106). The GUI also displays the menu bar 
(step 108) which allows the Auto Management feature 46 to 
be selected. 

FIG. 6 shows the steps for monitoring the health of the 
network. The user selects the Auto Management feature 46 
from the menu bar of the Console Program 44 (step 200)and 
the network manager 26 generates the Properties dialog box 
(step 202). The user enables Automatic Management (step 
204) and selects a Management Behavior (step 206). If the 
user selects Default behavior (step 208), the network man- 
ager 26 sends the default event requests at every polling 
interval to the devices 20, 22, 24 and 25 indicated in the 
network topology database 42 (step 210). If the user selects 
Custom behavior, the network manager 26 reads the cus- 
tomized event requests from the network topology database 
42 (step 212) and sends the customized event requests at 
every polling interval to the devices 20, 22, 24 and 25 
indicated in the network topology database 42 (step 214). 

FIG. 7 shows the steps for creating customized requests. 
The user clicks on the Customize button from the Auto 
Management feature 46 (step 300). The network manager 26 
reads the components from the network topology database 
42 (step 302) and the predefined event requests from the 
Predefined Request file stored in the non-volatile memory 38 
(step 304). Then the network manager 26 generates the 
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Customize popup dialog box, which displays the columns of 
components and predefined event requests (step 306). The 
user creates a customized request by selecting a component 
and associating it with a predefined event request (step 308). 
The network manager 26 displays the associated pair, that is, 
the customized request in a separate column(step 310). The 
network manager 26 also stores the customized request in 
the network topology database 42 in the instance file of the 
associated component (step 312). 

FIG. 8 shows the steps for creating a predefined event 
request. The user clicks on the Create Predefined Request 
button from the Customize popup dialog box (step 400) and 
the network manager 26 generates the Create Request win- 
dow 50 (step 402). The Create Request window 50 displays 
the fields of a predefined event request (step 404). The name 
of the predefined event request and the variable/threshold 
pair(s) for the attributes list are filled in by the user (step 
406). After the fields are filled out, the user clicks on the 
Save button and the predefined event request is added to the 
Predefined Request file in non -volatile RAM 38 (step 408). 
The destination address for the predefined event request is 
filled in when the predefined event request is actually sent. 

Thus disclosed is a customized apparatus and method that 
provides flexibility in monitoring an internet, a subnetwork 
or even a particular device on a network. Events can be 
defined by the network administrator, and each request can 
be configured for a specific device. 

It is understood that various changes and modifications 
may be made without departing from the spirit and scope of 
the invention. The invention is not limited to the internet 
configuration shown in FIG. 1. Moreover, the invention is 
not limited to network managers including workstations 
having RISC processors that run "UNIX"-based operating 
systems. For example, the network manager can include a 
personal computer having an x86 or "PENTIUM" processor 
that runs a 32-bit "UNIX"-based operating system such as 
"SOLARIS" 2.4. The operating system does not even have 
to be "UNIX"-based. 

The software for the network manager is not limited to the 
objects or the object-oriented design shown in FIG. 3. The 
software can be developed according to any methodology 
and any programming language. The Console program 44 is 
not limited to a GUI for displaying the elements and 
generating and firing the event requests. Display, generation 
and firing can be performed directly by the Console program 
44. 

Accordingly, the present invention is not limited to the 
precise embodiments described hereinabove. Instead, it is 
defined by the claims that follow. 

We claim: 

1. A method of monitoring a plurality of network devices, 
comprising the steps of: 

reading a plurality of predefined event requests from 
computer memory; 

each predefined event request including at least one 
variable/threshold pair where the variable in each pair 
corresponds to a variable whose value is stored in a 
respective network device's Management Information 
Base and the threshold in each pair is a threshold value 
for the variable in that pair, each variable/threshold pair 
defining an event corresponding to the variable in the 
pair reaching a value having a predefined relationship 
to the threshold in the pair; 

in response to a user request, 
displaying a list of devices, and 
displaying a list of predefined event requests; 

in response to user customization commands, generating 
customized event requests by associating various ones 
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of the displayed devices with various ones of the 
displayed predefined event requests, wherein at most 
one respective predefined event request is associated 
with each device; 
5 periodically sending the customized event requests to the 
devices with which they have been associated; 
receiving response messages from the devices in accor- 
dance with the predefined event requests sent to the 
devices; and 

io indicating status of the responding devices according to 
the response messages that are received. 

2. The method of claim 1, further comprising the step of 
generating at least one of the predefined event requests by 
forming a variable/threshold pair and storing it in a pre- 

15 defined event request data structure. 

3. The method of claim 1, further comprising the step of 
generating at least one predefined event request by forming 
a plurality of variable/threshold pairs and storing the formed 
pairs in the event request, such that multiple events for the 
associated device are defined. 

20 4. The method of claim 1, wherein the step of generating 
is performed by selecting a device from the list of devices 
and a predefined event request from the list of predefined 
event requests to be associated with the selected device, 
wherein the selecting step is performed one time for a device 

25 in the list of devices. 

5. The method of claim 1, further comprising the steps of: 
generating a graphical user interface having means for a 

user to select custom automatic management; and 
reading, generating and sending the customized event 
30 requests when custom automatic management is 
selected; and 

sending default event requests to the devices when custom 
automatic management is not selected. 

6. The method of claim 1, further comprising the steps of: 
35 monitoring at least some of the devices; 

displaying the devices that are being monitored, the 
displayed devices being represented by glyphs; and 

color-coding the glyphs to indicate the status of the 
devices being monitored. 

7. An apparatus for automatically monitoring a plurality 
of devices on a network, comprising: 

memory for storing a plurality of different predefined 
event requests; and 
45 each predefined event request including at least one 
variable/threshold pair where the variable in each pair 
corresponds to a variable whose value is stored in a 
respective network device's Management Information 
Base and the threshold in each pair is a threshold value 
so for the variable in that pair; each variable/threshold pair 
defining an event corresponding to the variable in the 
pair reaching a value having a predefined relationship 
to the threshold in the pair; 
a processor for reading the predefined event requests from 
55 the memory, 

in response to a user request, 
displaying a list of devices, and 
displaying a list of predefined event requests; 
generating a customized event request by associating at 
60 least one of the displayed predefined event requests 

with at least one of the displayed devices in response 
to user customization commands, wherein at most 
one respective predefined event request is associated 
with each device, and 
65 periodically, at a defined polling interval, transmitting 
the customized event request to the respective 
device; 
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receiving response messages Crom the devices in accor- 
dance with the predefined event requests sent to the 
devices; and 

indicating status of the responding devices according to 
the response messages that are received. 

8. The apparatus of claim 7, wherein the processor also 
generates the predefined event requests and stores the gen- 
erated predefined event requests in the memory. 

9. The apparatus of claim 8, wherein the processor gen- 
erates each predefined event request by receiving at least one 
variable/threshold pair and writing each received pair in a 
predefined event request data structure. 

10. The apparatus of claim 8, further comprising a video 
monitor and at least one input device, wherein the processor 
generates a graphical user interface for receiving the at least 
one variable/threshold pair and for allowing the event 
requests to be associated with the devices. 

11. The apparatus of claim 10, wherein the processor 
selectively displays glyphs representing the devices on the 
video monitor, and wherein the processor color-codes the 
glyphs to indicate status of the displayed devices. 

12. The apparatus of claim 8, wherein the processor is 
programmed to: 

display glyphs representing the devices 
receive responses from the devices; and 
display status of the devices based on the received 
responses. 

13. The apparatus of claim 12, wherein the processor is 
programmed to indicate status by color-coding the glyphs. 

14. The apparatus of claim 8, wherein the processor 
generates a graphical user interface having means for a 

user to select custom automatic management; and 
reads, generates and sends the customized event requests 
when custom automatic management is selected, and 
wherein the processor sends default event requests to 
the devices when custom automatic management is not 
selected. 

15. A computer program product for monitoring a plural- 
ity of network devices, the computer program product 
comprising a computer readable storage medium and a 
computer program mechanism embedded therein, the com- 
puter program mechanism comprising: 

a plurality of different predefined event requests; and 

each predefined event request including at least one 
variable/threshold pair where the variable in each pair 
corresponds to a variable whose value is stored in a 
respective network device's Management Information 
Base and the threshold in each pair is a threshold value 
for the variable in that pair, each variable/threshold pair 
defining* an event corresponding to the variable in the 
pair reaching a value having a predefined relationship 
to the threshold in the pair; 

a first set of instructions that read the predefined event 
requests from a memory, 

a second set of instructions that 
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in response to a user request, 
display a list of devices, and 
display a list of predefined event requests, and 

generate customized event requests by associating vari- 
ous one of the displayed predefined event requests 
with various ones of the displayed devices in 
response to user customization commands, wherein 
at most one respective predefined event request is 
associated with each device, and 
a third set of instructions that periodically, at a defined 

polling interval, transmit the customized event request 

to the respective devices; 
a fourth set of instructions that receive response messages 

from the devices in accordance with the predefined 

event requests sent to the devices; and 
a fifth set of instructions that indicate status of the 

responding devices according to the response messages 

that are received. 

16. The computer program product of claim 15, further 
comprising a sixth set of instructions that generate the 
predefined event requests and stores the generated pre- 
defined even requests in the memory. 

17. The computer program product of claim 16, further 
comprising instructions that generate each predefined event 
request by receiving at least one variable/threshold pair and 
writing each received pair in a predefined event request data 
structure. 

18. The computer program product of claim 16, further 
comprising instructions that generate a graphical user inter- 
face for receiving the at least one variable/threshold pair and 
allow the predefined event requests to be associated with the 
devices. 

19. The computer program product of claim 18, further 
comprising instructions that display glyphs representing the 
devices on a video monitor, and color-code the glyphs to 
indicate status of the displayed devices. 

20. The computer program product of claim 16, further 
comprising instructions that: 

display glyphs representing the devices; 
receive responses from the devices; and 
display status of the devices based on the received 
responses. 

21. The computer program product of claim 20, further 
including instructions that indicate status by color-coding 
the glyphs. 

22. The computer program product of claim 16, further 
including instructions that 

generate a graphical user interface having means for a 
user to select custom automatic management; and 

read, generate and send the customized event requests 
when custom automatic management is selected, and 
that send default event requests to the devices when 
custom automatic management is not selected. 



